Intel SGX 〜商用利用編〜
商用化事例
検索してもほとんどヒットせず。
zabeth.icon > 少なくともC向けだと下記事例くらいしかない？
エンタープライズだと基本的にはPoCや利用検討段階？
Windows端末での指紋認証
Dell, Lenovoの一部端末
zabeth.icon ページにはSGXの記載はないが多分実装されている...?
UHD BDの再生要件
zabeth.icon > セキュリティやコピー防止...?
Nintendo switch
クラウド対応状況
AWS
未対応（検索してもそれらしき情報がヒットせず）
GCP
未対応（検索してもそれらしき情報がヒットせず）
Azure
AzureのMarketplaceにある機能
2019/10時点ではEast USとWest Europeの２つのリージョンでのみ利用可能
設定項目
https://gyazo.com/548bcd39d93280cb113985ddd71ae98b
IBM Cloud
利用事例
1password
1Passwordで生成した鍵をSGXのenclave内に保存したり、暗号学的計算をSGXのenclave内で実行できるようになる
1Passwordのmaster keyを使ってパスワードをdecryptoする作業をSGX内に閉じ込めることができるので、一部のlocal attackに対して強くなる
2017年1月ごろからサポート開始？
最初は1Password for Windowsのみ対応
Signal
Signalはプライバシー保護に特化したメッセンジャーアプリ メッセージと通話ｗｐエンドツーエンドで暗号化
2017/9の記事
Signal運営側に連絡先を公開しないまま、ローカルの連絡先をSignalアプリでimportするにはどうしたらいいか？
プライバシー保護を重視するSignalとしてはユーザーの連絡先情報を保持したくない
ただ、登録後連絡先がゼロであることもUX的に避けたいので、ローカル端末に保存された連絡情報を取得して登録済みのSignalユーザーのリストを返したい
Intel SGXを使って上記課題を解決する
今まで
1. 電話番号のハッシュ値をSignalに送る
2. すでにSignalにユーザー登録済みの番号のハッシュ値と突合して一致するハッシュ値があればそのユーザー情報を返す
この方法だと番号の組み合わせ的に全通り試せるサイズなので問題がある（SignalがUserのアドレス帳の中身を把握できてしまう。）
Intel SGXを使う場合
1. 安全なSGX enclaveでcontact discoveryを実行
2. contact discoveryを実行したいclientは、remote OSからenclaveまで安全な接続を行う
3. clientはenclave内で実行されているコードが公開されていると予想されるオープンソースコードと同じであることを確認
4. clientは暗号化された識別子をアドレス帳からremove OSのenclaveに送信
5. enclaveは登録されたすべてのユーザーのセットでclientから送られてきた連絡先を検索し、結果を暗号化してclientに返す
Corda
Corda calls the process of asking a peer for transaction histories and verifying the results resolution. By putting the resolution process inside an SGX enclave — an encrypted tamper resistant memory space — it becomes possible to fully encrypt the ledger such that nobody has access to data they aren’t supposed to.
SGXの中に閉じてTx検証を行うことでTxの中身を関係者以外に一切漏らすことなく妥当性検証をできるということかな？
zabeth.icon > Corda理解してる人に何が嬉しいのか解説してほしい...!!!
↑ etaro先生の解説は下記の通り
CordaではTXのglobal broadcastはせず、TXに当事者同士が署名してfinalityという形(だから当事者以外には取引TX内容は見えない)
AとBの取引であれば、AがTX(state遷移)を作成してBに提案して同意署名を求める
BはAが提示してきたTXに署名する際に、そのTXのinputになっているUTXOが有効かを確かめるために、そのUTXOのhistoryを検証する必要がある
その際にhistoryデータから他人のTX履歴がBに見えてしまうというプライバシー問題がある
このプライバシー問題を解決するためにhistoryの検証をSGX内で(inputの中身が見えない形)で行う」
Hyperledger Fabric
一応公式レポジトリ...? （fabric本体のレポジトリはhyperledgerチーム。not hyperledger-labs）
本レポジトリはあくまでPoC（not for production）で、ver1.4のHyperledger Fabricに対応（現在の最新だが、メジャーバージョン2には対応しなさそう）
https://gyazo.com/c40a8d8892b50148cf031933b985895b
Chaincode enclave -> chaincodeを実行、chaincodeごとに存在
Enclave registryでchaincode enclaveと利用しているchaincodeの証明を保持
Enclave transaction validator -> chaincode enclaveの実行結果をvalidate
ChaincodeはSGX用にC（C++かな？）で書かないといけない
zabeth.icon なにが嬉しいのかわからないぞ...?
Peerを持っている時点でそのPeerが所属するChannelのデータは受け取れるから暗号化したり計算を秘匿化する必要性がない
Private Data -> 特定Peer間でのみデータを共有
chaincode on IGC -> 特定のPeer間でのみデータを共有 with 暗号化？
zabeth.icon 特定のPeerだけかどうかは設計依存ですね
Hyperledger Fabricの場合、PeerではTxバリデーションの都合上、必ず一度は生データが露見
zabeth.icon stateを暗号化して保存してもいいけど、validation過程で一度生に戻る（たぶん）
暗号化＋SGX内でのvalidation -> 生データを一度も露出せずに検証＆暗号化したデータをledger保持可能
暗号化したデータはもちろん通常のledgerに保存